In the client/server World Wide Web of Internet computing that we live in today, increasing numbers of Web based applications are being developed—an example of which is electronic commerce (e-commerce) or ‘business on the Web’. A Web based application includes the functionality of a Web server servicing a request received through the Web from a client (i.e., a Web request). The development of Web based applications includes the task of finding errors in programming code, often referred to as ‘debugging’ a computer program. Errors in programming code can also show up when a Web server services a Web request received through the Web from a client.
Common issues in debugging Web applications include finding out what is happening with a client system and what is happening with a Web application running on the client system. In order to diagnose issues on servers and clients, such as performance on a Web request and/or issues of a failed Web request, no easy way exists to figure out what's going on while a Web request is being processed. One way to diagnose such issues is to trigger a dump of the right processes at the right time. Then, after the often quite large dump has been retrieved, a review of the contents of one or more files of the dump is needed to find one or more sources of a poor request performance or of a Web request failure. This dump review process can require highly skilled diagnostic personnel in order to be performed properly and it may be quite difficult for skilled diagnostic personnel to find the source of the failed Web request. Moreover, evidence of a poor request performance or of a Web request failure might not even be in the dump since more often than not the dump will be triggered at a time when the client and the server are properly operating.
Another common problem in debugging Web requests is figuring out where performance issues arise on specific kinds of Web requests. For instance, diagnosis that is global across an entire server so as to hit all Web requests is not granular enough to be practical. If a particular kind of Web request has severe latency problems and that Web request involves a plurality of installed filters, it may be necessary to review a dump reporting on all of the filters in order to find out that a problem is arising with only one of the installed filters. Alternatively, it may be necessary to enable one filter at a time and perform successive individual tests for each of the installed filters to find out if a problem is arising with only one of the installed filters. These types of problem resolution efforts can be time consuming.
Still another common problem in debugging Web requests is figuring out why a specific Web request stops being serviced (e.g., ‘hangs’). Again, this may require the triggering of a dump and reviewing content of the dump files, where the dump was hopefully triggered at an appropriate time to include evidence of Web request servicing errors. Even then, the right amount of information in the dump files may be insufficient for a proper diagnosis or may be too verbose to be practical for debugging any one of several Web requests that are reflected in the dump files. Yet another problem with debugging some Web requests is that, in order to perform a proper debugging analysis, the specific Web request must not ‘hang’ but must continue on to completion of the Web request before all of the events for that Web request are stored and accessible for diagnostic analysis.
One source of problems in debugging Web request problems is that operating personnel may just cancel a Web request hosting process when a Web request servicing problem occurs. Unfortunately, this can remove any trace or evidence needed for a proper diagnosis of the Web request servicing problem.
Another type of difficulty in Web request servicing problem diagnosis is when code does not stop executing as soon as a bug occurs and the bug occurs without any error being signaled. As a result, the ‘bug’ is not noticed until long after the bug has occurred. Then, diagnostic personnel must undertake the often difficult task of finding how and where the bug occurred during execution of the code—such as by sifting through a voluminous amount of data in one or more dump files.
It would be an advance in the art to document (e.g., create a ‘trace’ for) a Web request as it proceeds throughout an entire servicing of the Web request, or a specifically identified portion thereof, by a Web server. The trace can then be used to easily identify one or more sources of a Web request servicing problem—thereby increasing the probability of having an easily reproducible test case that can be used in debugging by a software developer or by diagnostic personnel.